Linux Cubed Series 2: Applications

home *** CD-ROM | disk | FTP | other *** search

/ Linux Cubed Series 2: Applications / Linux Cubed Series 2 - Applications.iso / editors / emacs / xemacs / xemacs-1.004 / xemacs-1 / xemacs-19.13 / INSTALL < prev next >

Wrap

Text File | 1995-08-26 | 26.4 KB | 593 lines

XEmacs Installation Guide Copyright (c) 1994, 1995 Board of Trustees, University of Illinois Copyright (c) 1994 Free Software Foundation, Inc. Permission is granted to anyone to make or distribute verbatim copies of this document as received, in any medium, provided that the copyright notice and permission notice are preserved, and that the distributor grants the recipient permission for further redistribution as permitted by this notice. Permission is granted to distribute modified versions of this document, or of portions of it, under the above conditions, provided also that they carry prominent notices stating who last changed them, and that any new or changed statements about the activities of the Free Software Foundation are approved by the Foundation. BUILDING AND INSTALLATION: 1) Make sure your system has enough swapping space allocated to handle a program whose pure code is 900k bytes and whose data area is at least 400k and can reach 8Mb or more. If the swapping space is insufficient, you will get an error in the command `temacs -batch -l loadup dump', found in `./src/Makefile.in.in', or possibly when running the final dumped XEmacs. Building XEmacs requires about 50 Mb of disk space (including the XEmacs sources). Once installed, XEmacs occupies about 38 Mb in the file system where it is installed; this includes the executable files, Lisp libraries, miscellaneous data files, and on-line documentation. If the building and installation take place in different directories, then the installation procedure momentarily requires 50+38 Mb. XEmacs requires an ANSI C compiler, such as LCC or GCC. 2) Consult `./etc/MACHINES' to see what configuration name you should give to the `configure' program. That file sometimes offers hints for getting around some possible installation problems. 3) In the top directory of the XEmacs distribution, run the program `configure' as follows: ./configure CONFIGURATION-NAME [--OPTION[=VALUE]] ... The CONFIGURATION-NAME argument should be a configuration name given in `./etc/MACHINES'. If omitted, `configure' will try to guess your system type by inspecting its environment; if it cannot, you must find the appropriate configuration name in `./etc/MACHINES' and specify it explicitly. If you don't want X support, specify `--with-x=no'. If you omit this option, `configure' will try to figure out for itself whether your system has X, and arrange to use it if present. Additional support can be included for the NeXTstep system by specifying the flag `--with-ns'. This is not yet fully supported. The `--x-includes=DIR' and `--x-libraries=DIR' options tell the build process where the compiler should look for the include files and object libraries used with the X Window System. Normally, your compiler should be able to find these by default; these options should only be necessary if you have your X Window System files installed in unusual places. The `--site-includes=DIR' and `--site-libraries=DIR' options allow you to specify additional places the compiler should look for include files and object libraries. You may specify multiple DIR's by enclosing the list in quotes. On some systems (noticeably Solaris) you may need to use `--site-runtime-libraries=DIR'. This will add -R versions of each path in addition to the -L versions. The `--with-gcc' option specifies that the build process should compile XEmacs using GCC. The `--with-lcc' option specifies that the build process should compile XEmacs using Lucid C. The `--compiler' option allows you to specify some other compiler to be used to compile XEmacs. It is compatible with both the `--with-gcc' and `--with-lcc' options, so if the compiler that you specify is a special version of either gcc or lcc, then use the appropriate --with-gcc or --with-lcc flag as well as the --compiler flag. If none of these flags is specified, `configure' will search for GCC in your load path, and use it if present. If you don't want to use GCC, specify `--with-gcc=no' and the compiler will then default to 'cc'. The `--cflags' option specifies the CFLAGS the build process should use when compiling XEmacs. If not used CFLAGS defaults to "-g -O" for gcc and "-g" for all other compilers. The `--dynamic' option specifies that configure should try to link emacs dynamically rather than statically. The `--const-is-losing' option is for use if you have trouble compiling due to the `const' storage class in C. This is defined by default. Most users should have no need to change this. The `--srcdir=DIR' option specifies that the configuration and build processes should look for the XEmacs source code in DIR, when DIR is not the current directory. You can use `--srcdir' to build XEmacs for several different machine types from a single source directory. Make separate build directories for the different configuration types, and in each one, build XEmacs specifying the common source directory with `--srcdir'. The `--prefix=PREFIXDIR' option specifies where the installation process should put XEmacs and its data files. This defaults to `/usr/local'. - XEmacs (and the other utilities users run) go in PREFIXDIR/bin (unless the `--exec-prefix' option says otherwise). - The architecture-independent files go in PREFIXDIR/lib/xemacs-VERSION (where VERSION is the version number of XEmacs, like `19.10'). - The architecture-dependent files go in PREFIXDIR/lib/xemacs-VERSION/CONFIGURATION (where CONFIGURATION is the configuration name, like mips-dec-ultrix4.2), unless the `--exec-prefix' option says otherwise. The `--exec-prefix=EXECDIR' option allows you to specify a separate portion of the directory tree for installing architecture-specific files, like executables and utility programs. If specified, - XEmacs (and the other utilities users run) go in EXECDIR/bin, and - The architecture-dependent files go in EXECDIR/lib/xemacs-VERSION/CONFIGURATION. EXECDIR/bin should be a directory that is normally in users' PATHs. For example, the command ./configure mips-dec-ultrix configures XEmacs to build for a DECstation running Ultrix, with support for the X11 window system. XEmacs currently requires X11 in order to run so no flag is needed to specify that fact. The `--run-in-place' option will make the installed binaries reference the source tree for the elisp files. The `--with-menubars=TYPE' option allows you to specify which X toolkit you wish to use for the menubar. The valid options are `lucid' and `motif'. The default is `lucid' which is a Motif-lookalike menubar. We highly recommend its usage over the real Motif menubar. The `--with-scrollbars=TYPE' option allows you to specify which X toolkit you wish to use for the scrollbars. The valid options are `lucid', `motif', and `athena'. The default is `lucid' which is a Motif-lookalike scrollbar. The `--with-dialogs=TYPE' option allows you to specify which X toolkit you wish to use for the scrollbars. The valid options are `athena' and `motif'. The `lucid' option is accepted and will result in the `athena' toolkit being used. If the Motif toolkit can be found the default is `motif'. Otherwise, the default is `athena'. The `--with-xpm' option specifies that XEmacs should support X Pixmaps. `configure' will attempt to detect if you have the Xpm libraries and define `--with-xpm' for you. The `--with-xface' option specifies that XEmacs should support X-Faces. `configure' will attempt to detect if you have the compface library and define `--with-xface' for you. The `--with-socks' option specifies that XEmacs should be built with SOCKS support. The `--with-tooltalk' option specifies that XEmacs should be built with ToolTalk support for interconnecting with other applications. ToolTalk is not yet supported on all architectures. The `--with-sparcworks' option specifies that XEmacs should be built with support for Sun Sparcworks 3.0.1. This functionality is only of use on SunOS 4.1.x and Solaris 2.x systems. The `--with-energize' option specifies that XEmacs should be built with support for the Lucid Energize system. (If you have not purchased Energize, specifying this option won't gain you anything.) The `--external-widget' option specifies that XEmacs should be built with support for being used as a widget. This functionality should be considered beta at best. The `--dont-have-xmu' option can be used if your vendor doesn't ship the Xmu library. The `--puresize' option can be used to change the amount of purespace allocated for the dumped XEmacs. The `--with-sound=TYPE' option specifies that XEmacs should be built with sound support. Native (`--with-sound=native') sound support is currently available only on Sun SparcStations, SGI's, HP9000s, and Linux. Network Audio Support (NAS) (`--with-sound=nas' or `--with-sound=both') is an extension to X that you may or may not have for your system. For NAS, you will probably need to provide the paths to the nas include and library directories to configure. `configure' will attempt to determine if your configuration supports sound and define --with-sound for you. If your native sound library is not in a standard location you can specify where it is with the `--native-sound-lib=LIB' flag. For Linux, `/dev/audio' is required for SunAudio files and `/dev/dsp' is required for raw data and WAVE format files. The `--rel-alloc' option can be used to either enable or disable use of the relocating allocator. Generally, it's best to go with the default configuration for your system. The `--with-epoch' option enables functionality taken from Epoch. The `--with-i18n3' option provides some internationalization support. It's a performance killer and it's not really packaged for general consumption. It's probably best to not bother with this...wait for the Mule integration which is currently in progress to be completed. The `--with-mule' option provides Mule support. This does not work yet. It should become fully functional in 19.14. The `--debug' and `--error-checking' options are intended for use only by the developers. `--debug' adds code to be compiled in for performing various tests. `--error-checking' adds additional tests to many of the commonly used macros. The `configure' program does not accept abbreviations for its options. Note that `configure' doesn't do any compilation or installation itself. It just creates the files that influence those things: `./Makefile', `src/Makefile', `./src/config.h' and others. For details on exactly what it does, see the section called `CONFIGURATION BY HAND', below. When it is done, `configure' prints a description of what it did and leaves a copy in the file `config.status'. That file is also a shell script which, when run, recreates the same configuration; it contains the verbal description as a comment. If `configure' exits with an error after disturbing the status quo, it removes `config.status'. The work of `configure' can be done by editing various files in the distribution, but using `configure' is supposed to be simpler. See the section called "CONFIGURATION BY HAND" below if you want to do the configuration yourself. 4) Look at `./lisp/paths.el'; if some of those values are not right for your system, edit the file `./lisp/site-init.el' containing XEmacs Lisp code to override them; you probably don't want to edit paths.el itself. YOU MUST USE THE LISP FUNCTION `setq' TO ASSIGN VALUES, rather than `defvar', as used by `./lisp/paths.el'. For example, (setq news-inews-program "/usr/bin/inews") is how you would override the default value of the variable news-inews-program (which is "/usr/local/inews"). Things may malfunction if the variable `directory-abbrev-alist' is not set up to translate "temporary" automounter mount points into the canonical form. The default value of this variable contains the translation ("^/tmp_mnt/" . "/") meaning translate "/tmp_mnt/net/FOO" into "/net/FOO", which is appropriate for the default configuration of the Sun automounter, but which may be inappropriate for different vendor's automounters, or if you have customized your mount-point names. Note that, on some systems, the code you place in site-init.el must not use expand-file-name or any other function which may look something up in the system's password and user information database. See `./PROBLEMS' for more details on which systems this affects. 5) Put into `./lisp/site-init.el' any Emacs Lisp code you want XEmacs to load before it is dumped out. Note that, on some systems, the code you place in site-init.el must not use expand-file-name or any other function which may look something up in the system's password and user information database. See `./PROBLEMS' for more details on which systems this affects. This file is nonexistent in the distribution. You do not need to create it if you have nothing to put in it. 6) Run `make' in the top directory of the XEmacs distribution to finish building XEmacs in the standard way. The final executable file will be named `src/xemacs'. If you want to have XEmacs's executable programs and data files installed as well, run `make install'. By default, XEmacs installs its files in the following directories: `/usr/local/bin' holds the executable programs users normally run - `xemacs', `etags', `ctags', `b2m', and `emacsclient'. `/usr/local/lib/xemacs-VERSION/lisp' holds the Emacs Lisp libraries; `VERSION' stands for the number of the XEmacs version you are installing, like `18.59' or `19.11'. Since the lisp libraries change from one version of XEmacs to another, including the version number in the path allows you to have several versions of XEmacs installed at the same time; this means that you don't have to make XEmacs unavailable while installing a new version. XEmacs searches for its lisp files in these directories, and then in `/usr/local/lib/xemacs/site-lisp/*'. `/usr/local/lib/xemacs-VERSION/etc' holds the XEmacs tutorial, the `yow' database, and other architecture-independent files XEmacs might need while running. VERSION is as specified for `.../lisp'. `/usr/local/lib/xemacs/lock' contains files indicating who is editing what, so XEmacs can detect editing clashes between users. `/usr/local/lib/xemacs-VERSION/CONFIGURATION-NAME' contains executable programs used by XEmacs that users are not expected to run themselves, and the DOC file. `VERSION' is the number of the XEmacs version you are installing, and `CONFIGURATION-NAME' is the argument you gave to the `configure' program to identify the architecture and operating system of your machine, like `mips-dec-ultrix' or `sparc-sun-sunos'. Since these files are specific to the version of XEmacs, operating system, and architecture in use, including the configuration name in the path allows you to have several versions of XEmacs for any mix of machines and operating systems installed at the same time; this is useful for sites at which different kinds of machines share the file system XEmacs is installed on. `/usr/local/lib/xemacs-VERSION/info' holds the on-line documentation for XEmacs, known as "info files". `/usr/local/man/man1' holds the man pages for the programs installed in `/usr/local/bin'. If these directories are not what you want, you can specify where to install XEmacs's libraries and data files or where XEmacs should search for its lisp files by giving values for `make' variables as part of the command. See the section below called `MAKE VARIABLES' for more information on this. 7) If your system uses lock files to interlock access to mailer inbox files, then you might need to make the program arch-lib/movemail setuid or setgid to enable it to write the lock files. We believe this is safe. The setuid/setgid bits need not be set on any other xemacs-related executables. 8) You are done! MAKE VARIABLES You can change where the build process installs XEmacs and its data files by specifying values for `make' variables as part of the `make' command line. For example, if you type make install bindir=/usr/local/gnubin the `bindir=/usr/local/gnubin' argument indicates that the XEmacs executable files should go in `/usr/local/gnubin', not `/usr/local/bin'. Here is a complete list of the variables you may want to set. `bindir' indicates where to put executable programs that users can run. This defaults to /usr/local/bin. `datadir' indicates where to put the architecture-independent read-only data files that XEmacs refers to while it runs; it defaults to /usr/local/lib. We create the following subdirectories under `datadir': - `xemacs-VERSION/lisp', containing the XEmacs lisp libraries, and - `xemacs-VERSION/etc', containing the XEmacs tutorial and the `yow' database. `VERSION' is the number of the XEmacs version you are installing, like `18.59' or `19.11'. Since these files vary from one version of XEmacs to another, including the version number in the path allows you to have several versions of XEmacs installed at the same time; this means that you don't have to make XEmacs unavailable while installing a new version. `statedir' indicates where to put architecture-independent data files that XEmacs modifies while it runs; it defaults to /usr/local/lib as well. We create the following subdirectories under `statedir': - `xemacs/lock', containing files indicating who is editing what, so XEmacs can detect editing clashes between users. `libdir' indicates where to put architecture-specific data files that XEmacs refers to as it runs; it too defaults to `/usr/local/lib'. We create the following subdirectories under `libdir': - `xemacs-VERSION/CONFIGURATION-NAME', containing executable programs used by XEmacs that users are not expected to run themselves and the DOC file. `VERSION' is the number of the XEmacs version you are installing, and `CONFIGURATION-NAME' is the argument you gave to the `configure' program to identify the architecture and operating system of your machine, like `mips-dec-ultrix' or `sparc-sun-sunos'. Since these files are specific to the version of XEmacs, operating system, and architecture in use, including the configuration name in the path allows you to have several versions of XEmacs for any mix of machines and operating systems installed at the same time; this is useful for sites at which different kinds of machines share the file system XEmacs is installed on. `infodir' indicates where to put the info files distributed with XEmacs; it defaults to `/usr/local/lib/xemacs-VERSION/info'. `mandir' indicates where to put the man pages for XEmacs and its utilities (like `etags'); it defaults to `/usr/local/man/man1'. `prefix' doesn't give a path for any specific part of XEmacs; instead, its value is used to determine the defaults for all the architecture-independent path variables - `datadir', `statedir', `infodir', and `mandir'. Its default value is `/usr/local'; the other variables add on `lib' or `man' to it by default. For example, suppose your site generally places GNU software under `/usr/users/software/gnusoft' instead of `/usr/local'. By including `prefix=/usr/users/software/gnusoft' in the arguments to `make', you can instruct the build process to place all of the XEmacs data files in the appropriate directories under that path. `exec_prefix' serves the same purpose as `prefix', but instead determines the default values for the architecture-dependent path variables - `bindir' and `libdir'. The above variables serve analogous purposes in the makefiles for all GNU software; here are some variables specific to XEmacs. `lispdir' indicates where XEmacs installs and expects its lisp libraries. Its default value, based on `datadir' (which see), is `/usr/local/lib/xemacs-VERSION/lisp' (where `VERSION' is as described above). `sitelispdir' indicates where XEmacs should search for lisp libraries specific to your site. XEmacs checks them in order before checking `lispdir'. Its default value, based on `datadir' (which see), is `/usr/local/lib/xemacs/site-lisp'. `etcdir' indicates where XEmacs should install and expect the rest of its architecture-independent data, like the tutorial and yow database. Its default value, based on `datadir' (which see), is `/usr/local/lib/xemacs-VERSION/etc' (where `VERSION' is as described above). `lockdir' indicates the directory where XEmacs keeps track of its locking information. Its default value, based on `statedir' (which see), is `/usr/local/lib/xemacs/lock'. `archlibdir' indicates where XEmacs installs and expects the executable files and other architecture-dependent data it uses while running. Its default value, based on `libdir' (which see), is `/usr/local/lib/xemacs-VERSION/CONFIGURATION-NAME' (where VERSION and CONFIGURATION-NAME are as described above). Remember that you must specify any variable values you need each time you run `make' in the top directory. If you run `make' once to build xemacs, test it, and then run `make' again to install the files, you must provide the same variable settings each time. To make the settings persist, you can edit them into the `Makefile' in the top directory, but be aware that running the `configure' program erases `Makefile' and rebuilds it from `Makefile.in'. The top-level Makefile stores the variable settings it used in the Makefiles for the subdirectories, so you don't have to specify them when running make in the subdirectories. CONFIGURATION BY HAND Running the `configure' program performs the following steps. 1) Copy `./src/config.h.in' to `./src/config.h'. 2) Consult `./etc/MACHINES' to see what configuration name you should use for your system. Look at the code of the `configure' script to see which operating system and architecture description files from `src/s' and `src/m' should be used for that configuration name. Edit `src/config.h', and change the two `#include' directives to include the appropriate system and architecture description files. 2) Edit `./src/config.h' to set the right options for your system. If you need to override any of the definitions in the s/*.h and m/*.h files for your system and machine, do so by editing config.h, not by changing the s/*.h and m/*.h files. Occasionally you may need to redefine parameters used in `./lib-src/movemail.c'. 3) If you're going to use the make utility to build XEmacs, you will still need to run `configure' first, giving the appropriate values for the variables in the sections entitled "Things `configure' Might Edit" and "Where To Install Things." Note that you may only need to change the variables `prefix' and `exec_prefix', since the rest of the variables have reasonable defaults based on them. For each Makefile variable of this type, there is a corresponding configure option; for example, to change the location of the lock directory, you might use ./configure --lockdir=/nfs/xemacslock The `configure' script is built from `configure.in' by the `autoconf' program. However, since XEmacs has configuration requirements that autoconf can't meet, `configure.in' uses an marriage of custom-baked configuration code and autoconf macros. New versions of autoconf could very well break this arrangement, so it may be wise to avoid rebuilding `configure' from `configure.in' when possible. BUILDING XEMACS BY HAND Once XEmacs is configured, running `make' or running the shell script `build-install' in the top directory performs the following steps. 1) Run `make src/paths.h' in the top directory. This produces `./src/paths.h' from the template file `./src/paths.h.in', changing the paths to the values specified in `./Makefile'. 2) Cd to `./lib-src' and run `make'. This creates executables named `ctags' and `etags' and `wakeup' and `make-docfile' and `digest-doc' and `test-distrib'. And others. 3) Cd to `./src' and Run `make'. This refers to files in the `./lisp' and `./lib-src' subdirectories using names `../lisp' and `../lib-src'. This creates a file `./src/xemacs' which is the runnable XEmacs, assigning it a new build version number by incrementing the build version stored in `./lisp/version.el'. It also creates a file in `./lib-src' whose name is `DOC' followed by the current XEmacs version. This file contains documentation strings for all the functions in XEmacs. Each time you run make to make a new xemacs, a new DOC file with a new name is made. You must keep the DOC file for an XEmacs version as long as you keep using that XEmacs version. INSTALLATION BY HAND The steps below are done by running `make install' in the main directory of the XEmacs distribution. 1) Copy `./lisp' and its subdirectories, `./etc', and the executables in `./lib-src' to their final destinations, as selected in `./src/paths.h'. Strictly speaking, not all of the executables in `./lib-src' need be copied. - The programs `cvtmail', `emacsserver', `env', `fakemail', `hexl', `movemail', `timer', `vcdiff', `wakeup', and `yow' are used by XEmacs; they do need to be copied. - The programs `etags', `ctags', `emacsclient', `b2m', and `rcs2log' are intended to be run by users; they are handled below. - The programs `make-docfile', `make-path', and `test-distrib' were used in building XEmacs, and are not needed any more. - The programs `digest-doc' and `sorted-doc' convert a `DOC' file into a file for users to read. There is no important reason to move them. 2) Copy the files in `./info' to the place specified in `./lisp/site-init.el' or `./lisp/paths.el'. Note that if the destination directory already contains a file named `dir', you probably don't want to replace it with the `dir' file in the XEmacs distribution. Instead, you should make sure that the existing `dir' file contains an appropriate menu entry for the XEmacs info. 3) Create a directory for XEmacs to use for clash detection, named as indicated by the PATH_LOCK macro in `./src/paths.h'. 4) Copy `./src/xemacs' to `/usr/local/bin', or to some other directory in users' search paths. `./src/xemacs' has an alternate name `./src/emacs-EMACSVERSION'; you may wish to make a symbolic link named `/usr/local/bin/xemacs' pointing to that alternate name, as an easy way of installing different versions. You can delete `./src/temacs'. 5) Copy the programs `b2m', `emacsclient', `ctags', `etags', and `rcs2log' from `./lib-src' to `/usr/local/bin'. These programs are intended for users to run. 6) Copy the man pages in `./etc' for xemacs, ctags, and etags into the appropriate man directories. 7) The files in the `./src' subdirectory, except for `xemacs', are not used by XEmacs once it is built. The source would be handy for debugging. PROBLEMS See the file PROBLEMS in this directory for a list of various problems sometimes encountered, and what to do about them.